(Temporary) caching cdn handler until we sort out bundling #4
Conversation
|
We may also want to support the use case where all the widgets are in a single bundle like with jupyterlab. The loading of external bundles could be activated as an opt-in. There are benefits to both use cases (all in one bundle, and bundles loaded separately). @jasongrout may have an opinion on that. |
|
I think it makes a lot of sense to support the local widgets only use case. |
|
We started having some in-depth discussions with @maartenbreddels about having a jupyterlab remix as a front-end for this, reusing the jupyterlab extension mechanism etc. Would love to brainstorm with you about this. |
|
Sounds great. Let's talk today or tomorrow. |
SylvainCorlay
force-pushed
the
master
branch
2 times, most recently
from
1a6bf44
to
36ecd86
Compare
SylvainCorlay
force-pushed
the
master
branch
2 times, most recently
from
bee9323
to
5dd3fbb
Compare
|
Would this help in making the load times a bit faster? |
|
Yes it would, what you can also do is put e.g. bqplot.js in the voila/static directory for now (If you open the browser dev console you should see it first tries to fetch that file before trying the cdn |
|
Closed due to inactivity |
(replaces #3)
Issue to solve
For loading js modules, we have to choose a system, either the notebook extension method or the jupyter lab bundling. This new loader (frontend) will be a temporary solution that will 'just work' until we find the proper way to do this. It will try to fetch from
<server>/voila/require/module@semver, which at the server willBut only for modules in a whitelist (security concern)
Issues:
It will not respect semver, so will never fetch a patched version once it cached a version.
Where cache?
It first tries
{prefix}/share/jupyter/voila_cache/{module}/{semver}, and on failure will use the user directory.